Your Project: The Mountain

Imagine your project as a mountain. Your team stands at its base and wishes to reach the other side. They swing their picks and shovels and dig into the work.

Although we have many methods to organize these efforts, three reign supreme: Agile, Lean, and Waterfall. Each concept can cover anything from manufacturing products to managing startups; however, we will talk about them as they pertain to digital projects. They can govern a part of a digital project or the entire thing. We will discuss all three. Let us tackle Waterfall first.

You are likely accustomed to Waterfall projects (see Figure 30-2). Here, we organize a project into discrete steps, such as research, design, development, and testing. The next step does not begin until the previous one has ended. You start by planning your course through the mountain. Next, you draft blueprints and design the supports. You ready the picks and shovels. Once preparations are complete, the digging begins.

Using Agile is like carving a tunnel through a mountain 10 feet at a time (see Figure 30-3). At the end of each 10-foot segment , you meet with your team and evaluate where you all stand. You stare at the chiseled walls of the tunnel and evaluate the project’s progress. You see that the team chipped away at some features and perhaps watched cracks form within others. Maybe a few sprung leaks. Everyone decides how to move forward, and another 10-foot dig begins. If you veer off course, you can correct it in the next segment. Through repeated segments, or “sprints,” the team reaches daylight at the other end.

With a Lean project, you choose the shortest route through the mountain—the “minimum viable” route (see Figure 30-4). You survey the landscape to avoid the hard features and potential cave-ins. You include only what is vital. Although the best path may be a longer one, the team forgoes an ideal solution in favor of speed. The team carves away at the project and quickly reaches an outcome on the other side.

On the surface, Waterfall, Agile, and Lean sound equally well suited to tackling a project. But, like tunneling through a mountain, all projects encounter obstacles along the way. We must plan for detours. It is easy to convince ourselves that the wrong course is the right one when we are stuck under a mountain of work. Let’s dig further into each one, starting with Agile.

Agile

Agile traces back to software development methodologies created in the 1960s. In the decades that followed, the strategies continued to evolve. By 2001, The Agile Manifesto ⁵ had introduced a cohesive concept of Agile based on lofty and inspiring goals: working software over documentation, flexible schedules over a rigid timeline, and collaboration over antagonism.⁶ Sounds pretty great, doesn’t it?

The Agile process and its varieties, such as Scrum and Kanban, have become the norm in large-scale development efforts. The quick path to functioning software does much to curb the apprehensions of today’s executives.

Development tasks lend themselves to Agile. Coding is a complex and artful task; however, code either works or it does not. If it meets performance goals then, by most accounts, the code is viable. Using Agile, you can build, test, and deploy almost anything, as long as it fits within a sprint. A sprint is any time-boxed interval, though most are a few weeks in length. You determine the work. You complete it. You test it. You deploy it. You move on to the next sprint. After several sprints, you arrive at a fully functioning product. This model works so well for some organizations that Agile has extended into Agile product development, Agile marketing and—what we will focus on next—Agile UX.

In several environments, Agile UX may be a perfect solution. We split a set of tasks into sprints and quickly see results. Our UX and development deliverables align. Everyone uses a common vernacular. The team digs 10 feet into the mountain, looks around, high-fives, and plans the next 10-foot increment. Tunnels get built.

But this immediacy is also where cracks begin to form within an Agile project. Although speed may be a virtue, it misses the small issues that, if left unaddressed, may grow into tremors, crumble the support for your project, and bury you alive. We make tradeoffs. Rather than wait for a research study, we interview only a handful of stakeholders. Rather than wait to build wireframes, we advance to a prototype. Rather than wait for conclusive testing results, we repair as we receive feedback. We trade clarity for speed, and contemplation for immediacy. These tradeoffs can be compelling, but they are also why Agile UX projects sometimes fail.

Why would an Agile UX project fail? After all, many UX research and design processes can be grouped into tasks, and these tasks are frequently iterative. Furthermore, UX deliverables are notoriously document-heavy, and Agile UX promises to lighten this load. People would rather play with a functioning prototype than trudge through detailed documentation. And lastly, people want software now, not months from now. It is hard to argue against any of those points. But I will.

Problems arise from the UX tasks themselves: several are linear and build upon one another. Experienced team members may appreciate the first stages of user experience design, but these early activities are intangible to novices. Research may appear too slow. Personas may appear too silly. Flowcharts may appear too abstract. Wireframes may appear too fastidious. The early steps of a UX process may appear to be sedentary: people talk about building a tunnel, but nobody is digging.

We must realize that digging a tunnel into a mountain and digging a tunnel into a volcano may look very much the same, at first. We do not notice the difference until we have reached the middle (see Figure 30-5). Some projects combust without effective planning and research. Planning and research reveal their worth over time. Conversely, we recognize their absence when it is already too late, after having squandered vital weeks on a flawed prototype. We find ourselves running, screaming, and searching for a project’s exit. With scorched eyebrows and charred egos, we promise to find a better way next time.

Much of UX design and research is about planning what to do—what will be experienced by users. UX design and research is the precursor to visual design and development. It creates the blueprint that charts a course through the mountain. It avoids the lava.

Lean

Lean UX is an evolution. It finds a halfway point between Waterfall and Agile. An excellent book on Lean UX is Jeff Gothelf and Josh Seiden’s Lean UX: Applying Lean Principles to Improve User Experience . The book contains a wealth of helpful tips on everything from team dynamics to prototyping.

At the core of Lean UX is the “minimum viable product”—an MVP . To explain this concept, let’s return to our example of digging a tunnel through a mountain.

A tunnel is a big project. It requires considerable time and resources. Your team needs an assortment of picks, shovels, and perhaps a few sticks of dynamite. All these resources cost money. We chisel, excavate, and detonate. All these activities take time.

With every project, we risk wasting time and resources. We chart the wrong course. We run into impenetrable obstacles. We dig into the wrong mountain.

The brilliance of Lean UX is its lack of ambition. If Lean UX had a rallying cry it would be “Let’s… not!” In essence, the minimum viable product is the shortest path to success. We reduce risk by avoiding large expenses of time and resources. It is akin to digging the shortest route through the mountain.

The route we take is not necessarily ideal, but by completing even this short path, we gain new knowledge. Along the way, we learn about potential pitfalls and uncover veins of gold. But our greatest learning comes from reaching the other side of the mountain. For the first time, we see what awaits us. We may learn that the resulting landscape is not worth the effort—best to stop now. We may learn that an ideal destination is nearly in reach—best to keep on digging.

You will find Lean UX practices within small startups and large corporations. An MVP serves as a proof of concept. More than a prototype, it demonstrates the crucial features of a product—not all, just the ones that make the product viable. For example, a map app should display maps. An auction site should accept bids. A banking kiosk should provide account balances. Once we achieve the minimal viable product, everything else becomes elective.

Determining what is crucial and what is elective challenges even the most experienced of teams. What should be included? Whereas an application’s stability may be viewed as crucial, an application’s aesthetics may not. Does an app require an optimum user experience? I think so, but you may feel differently. A Lean UX project includes only the necessary. It is practical. It is realistic. And, it is often rather boring.

An MVP rarely stirs the heart—it is the minimum , after all. Much of what compels users are the product’s details: the micro-interactions, the small gestures, and the tailored experiences. Although the minimum gets the product out your door, it does not necessarily get it into a customer’s.

An MVP provides us with a start: a glimpse of the other side of the mountain. We can either abandon our effort or keep on digging. Our goal is to reach an ideal state—a product that not only offers the minimum but also all the electives that make an experience optimal and enjoyable.

The key to reaching this promised land is buried somewhere deep within your project. You only need to look. Start with an MVP . Add, edit, and delete until the experience is so ideal, so perfect, that no other path through the mountain would be as gratifying.

A Bit of This, a Bit of That

As we conclude this chapter about Waterfall, Agile, and Lean, we should reflect on our earlier discussions about being human. Because, over time, we realize that any discussion of process is actually about people.

We need not divide ourselves into separate tribes of project managers, designers, or developers. Our commonalities are the key to working with one another. All of us are remarkably similar: we wish to succeed, and we fear restrictions. Yet, if we are honest with ourselves, we must admit that we find comfort in imposing limitations on others. To do so gives us a sense of predictability and safety.

Even those who say, “we do not need a process,” are often the first people to demand guidance at the first sign of difficulty. Thus, we must acknowledge this need for predictability, for people can erect walls as easily as they can dig tunnels. A good process provides a means of protection, as well as action.

Is there a best process, one that works every time—a secret to combining inspiration, expertise, rigor, profit, and personal satisfaction? The honest answer is no. We live in a world governed by happenstance: economies thrive or take downturns, clients succeed or go bankrupt, users become loyal or defect to our competitors. Too many processes attempt to satisfy all people, tasks, and timelines. A process tailored to social marketing may fail when developing enterprise software. One befitting seasoned managers may fail when applied to recent college graduates. Your process has little-to-no effect outside your office’s walls.

Where does this leave us? Though no process is perfect, a common thread runs through many successful ones. You can leverage the speed of some and the clarity of others, building a process suited to your particular circumstances.

We need not choose only from among Waterfall, Agile, and Lean. These methodologies can improve work, but there is more than one way to tunnel through a mountain. You could research a project using Waterfall, design a product using Lean, and end your development with Agile… or vice versa… or by applying any other combination.

It would be naive to think that all situations can be covered by a single process. Choose what works best for you. After all, you are the one doing the digging.

Key Takeaways

Questions to Ask Yourself